Mobile device and key fob pairing for multi-factor security

ABSTRACT

Systems and methods may provide for determining a first proximity status of a first mobile device with respect to a vehicle, and determining a second proximity status of a second mobile device with respect to the vehicle. Additionally, an accessibility of one or more functions of the vehicle may be configured based at least in part on the first proximity status and the second proximity status. In one example, a policy associated with one or more of the first mobile device and the second mobile device may be identified, wherein the accessibility is configured further based on the policy.

BACKGROUND

Embodiments generally relate to security systems. More particularly,embodiments relate to the use of multiple factors to control access tovehicles.

Vehicle entry systems may include proximity-based keyless remotes (e.g.,key fobs) that may be used to access and/or start the vehicle. Whilethese solutions may be suitable under certain circumstances, thereremains considerable room for improvement. For example, unauthorizedaccess and/or operation of the vehicle may be achieved by simply gainingpossession of the key fob, which may be the sole user authenticationfactor with respect to the vehicle. Moreover, if the key fob is lost orstolen, a new key fob may need to be ordered, which may be ofconsiderable cost, delay and inconvenience to the owner. Althoughcertain smart phone applications may allow remote control of vehicles,these applications may also be limited to the use of login credentialsto establish the phone as the only user authentication factor withrespect to the vehicle, wherein the login credentials may be easilycompromised. Moreover, smart phone-based solutions may involve the useof an intermediary (e.g., service provider) between the phone and thevehicle.

BRIEF DESCRIPTION OF THE DRAWINGS

The various advantages of the embodiments of the present invention willbecome apparent to one skilled in the art by reading the followingspecification and appended claims, and by referencing the followingdrawings, in which:

FIG. 1 is a block diagram of an example of an authentication environmentaccording to an embodiment;

FIGS. 2A and 2B are block diagrams of examples of factor replacementscenarios according to embodiments;

FIG. 3 is a block diagram of an example of a logic architectureaccording to an embodiment;

FIG. 4 is a block diagram of an example of a set of user profilesaccording to an embodiment;

FIG. 5 is a flowchart of an example of a method of managing amulti-factor authentication environment according to an embodiment;

FIG. 6 is a block diagram of an example of a processor according to anembodiment; and

FIG. 7 is a block diagram of an example of a system according to anembodiment.

DETAILED DESCRIPTION

Turning now to FIG. 1, an authentication environment 10 is shown inwhich access to and control over a vehicle 14 is managed relative to aplurality of mobile devices 16, 18 that are paired with the vehicle 14.In the illustrated example, a first mobile device 16 is a key fob (e.g.,wireless hardware security token) and a second mobile device 18 is asmart phone. The mobile devices 16, 18 may also include other types ofdevices such as smart tablets, personal digital assistants (PDAs), mediaplayers, imaging devices, and so forth, wherein a user 12 may carry themobile devices 16, 18 with him or her as the user approaches andinteracts with the vehicle 14. As will be discussed in greater detail,the presence of the mobile devices 16, 18 may be required in order toauthenticate the user 12, wherein successful authentication may resultin certain functions of the vehicle 14 being made available to the user12. For example, the presence of both mobile devices 16, 18 may berequired before the user 12 is permitted to access the vehicle 14 (e.g.,door and/or trunk unlock function), start the vehicle 14 (e.g., ignitionfunction), customize various settings (e.g., user setting function),drive the vehicle 14 (e.g., vehicle operation function), pair deviceswith the vehicle 14 (e.g., device pairing function), and so forth.Accordingly, the illustrated environment 10 represents a “multi-factor”authentication environment in which the security of the vehicle 14 is afunction of the proximity status of multiple mobile devices 16, 18.

As will also be discussed in greater detail, user policies and/orprofiles may also be used to make certain functions, such as vehicleaccess and device pairing, available to the user 12 even if only one ofthe mobile devices 16, 18 is present. Additionally, although two mobiledevices are shown, more than two mobile devices may also be used by agiven user to access vehicle functions. For example, the user 12 maypair a smart phone, smart tablet and media player with the vehicle 14,and designate the smart phone as the primary (e.g., “master”) device,wherein the primary device may be used to pair other devices with thevehicle 14.

For example, FIG. 2A demonstrates that a policy may be implemented inwhich the user 12 is permitted to enter the vehicle 14 if the firstmobile device 16 is present but the second mobile device 18 is notpresent. Such a case might occur if the second mobile device 18 becomeslost or stolen, or the user 12 merely forgets to bring the second mobiledevice 18. The policy, which may be implemented as a user profilecorresponding to the user 12 or as a global policy (e.g., defaultprofile) applicable to all users or groups of users, may also permit areplacement device 20 (e.g., smart phone) to be paired with the vehicle14, provided that the user 12 successfully satisfies a login constraint(e.g., inputs a predefined passcode) associated with the user profile ofthe user 12 and completes a pairing process.

Similarly, FIG. 2B demonstrates that the user profile may permit theuser 12 to enter the vehicle 14 if the second mobile device 18 ispresent but the first mobile device 16 is not present. Such a case mightoccur if the first mobile device 16 becomes lost or stolen, or the user12 merely forgets to bring the first mobile device 16. The user profilemay also permit a replacement device 22 (e.g., key fob) to be pairedwith the vehicle 14, provided that the user 12 successfully satisfiesthe login constraint associated with the user profile of the user 12 andcompletes the pairing process. Accordingly, the use of a multi-factorauthentication scheme may enable new factors to be paired with thevehicle 14 at considerably less cost, delay and inconvenience to theuser 12, while maintaining a relatively high level of security withrespect to the vehicle 14.

Turning now to FIG. 3, a logic architecture 24 (24 a-24 d) is shown,wherein the logic architecture 24 may be generally incorporated into avehicle such as, for example, the vehicle 14 (FIGS. 1, 2A and 2B) ashardware, software, firmware, or any combination thereof. In theillustrated example, a first factor module 24 a uses a proximity sensor(not shown) to determine a first proximity status of the first mobiledevice 16 with respect to the vehicle. Similarly, a second factor module24 b may user a proximity sensor to determine a second proximity statusof the second mobile device 18 with respect to the vehicle. A securitymodule 24 c may have a request component 40 that receives a user requestvia a user interface (UI) 30 (e.g., pushbutton, switch, etc.) of thefirst mobile device 16, a UI 32 (e.g., touch screen, microphone, etc.)of the second mobile device 32, a UI 34 (e.g., door handle, pushbutton,touch screen, etc.) of the vehicle, etc., and configure an accessibilityof one or more functions 26 (26 a-26 c) of the vehicle in response tothe user request based at least in part on the first proximity statusand the second proximity status. In one example, the security module 24c identifies a policy such as one or more user profiles 28, wherein atleast one of the user profiles 28 may be associated with the firstmobile device 16 and/or the second mobile device 18 (and a usercorresponding to such device(s)). In such a case, the vehicle functions26 may be configured further based on the identified user profile.

For example, the security module 24 c might have a denial component 36that denies user requests if the first proximity status and the secondproximity status do not satisfy a multi-factor condition of the userprofile. More particularly, the multi-factor condition may stipulatethat both mobile devices 16, 18 (e.g., factors) be present in order forthe vehicle function in question to be available to the user. In such acase, if the first proximity status indicates that the first mobiledevice 16 is present but the second proximity status indicates that thesecond mobile device 18 is not present, the multi-factor condition wouldnot be satisfied. Similarly, if the second proximity status indicatesthat the second mobile device 18 is present but the first proximitystatus indicates that the first mobile device 16 is not present, themulti-factor condition would also not be satisfied.

Other conditions, such as time-based or location-based conditions mayalso be used. For example, if the user profile stipulates that the userin question (or all users if a global policy and/or default profile isimplemented) is to operate the vehicle within a certain radius of aparticular location (e.g., street address) and it is determined that thevehicle is outside that radius, the denial component 36 may denyoperation of the vehicle (e.g., prevent ignition of the vehicle,shutdown the vehicle after providing a warning to the driver, etc.). Byway of another example, if the user profile stipulates that the user inquestion is to operate the vehicle within a certain time period and itis determined that the current time is outside the specified timeperiod, the denial component 36 may also deny operation of the vehicle.In addition, enforcement of the multi-factor conditions may be conductedon an ongoing basis. For example, if it is determined that, after agiven user request has been granted, a condition leading to the grant ofthe request is no longer satisfied, the grant of the condition may beeffectively reversed. Thus, shutdown of the vehicle may be implementedin such a scenario as well. Other examples may include the prohibitionof radio usage while the vehicle is being operated to prevent distracteddriver scenarios.

The security module 24 c may also have a grant component 38 that grantsuser requests if the first proximity status and the second proximitystatus satisfy the multi-factor condition of the user profile. As willbe discussed in greater detail, the grant component 38 may also applyone or more constraints such as, for example, a time constraint,location constraint, login constraint, etc., of the user profile to thevehicle function in question. With specific regard to the loginconstraint, the illustrated architecture 24 also includes a pairingmodule 24 d configured to pair the first and second mobile devices 16,18, as well as replacement devices such as device 20 (FIG. 2A) anddevice 22 (FIG. 2B), with the vehicle. The mobile devices 16, 18, andreplacement devices 20 (FIG. 2A), 22 (FIG. 2B) may also be paired withone another. If both factors are present, the pairing module 24 d maymanage the pairing process normally. If, on the other hand, only one ofthe factors is present, the pairing module 24 d may permit entry to thevehicle and then prompt the user to enter a passcode (e.g., personalidentification number/PIN, password, etc.) before proceeding with thepairing process.

With further regard to the pairing module 24 d, the passcode may beentered on one of the mobile devices 16, 18, or in some embodiments maybe required to be entered directly into the vehicle UI 34 in order topair the devices 16, 18. In another embodiment, automatic pairing may beenabled, wherein a default policy and/or user profile may be used untila “master” (e.g., primary) device is defined. For example, one devicemay be considered to be a master that is to be present in order to pairother devices together and with the vehicle (one master key fob, forinstance). In some embodiments, pairing may only be completed when themaster device is also present (e.g., in order to pair a lesserprivileged smart phone, for instance, operated by a child, minor, orother non-owner of the vehicle and a smart phone). In some embodiments,a second device (e.g., smart phone rather than key fob) may beidentified as a master device at the time of pairing to enable entry ofuser constraints on other secondary devices. These other secondary“non-master” devices (e.g., lesser privileged smart phone) may beprevented from changing their own user constraints. Secondary devicesmay receive user constraints to be stored on the device via a number ofmeans: Bluetooth, wireless, NFC (near field communication), synching tocomputer or other docking station, etc. The user constraints may then benon-modifiable, however except in the presence of the master device.

Additionally, the illustrated security module 24 c has a notificationcomponent 42 configured to generate a notification via the UI 30 of thefirst mobile device 16, the UI 32 of the second mobile device 18, and/orthe UI 34 of the vehicle if either the first proximity status indicatesthat the first mobile device is not present or the second proximitystatus indicates that the second mobile device is not present. Moreparticularly, such a notification may be useful in cases where a bonafide user is attempting to operate the vehicle without one of thefactors (e.g., forgotten factor is missing) as well as cases where anunauthorized user is attempting to operate the vehicle without one ofthe factors (e.g., stolen factor is present). The notification may besent to the nearby factor (e.g., in the case of a forgotten factor)and/or the missing factor (e.g., in the case of a stolen factor),depending upon the circumstances.

In the illustrated example, each of the mobile devices 16, 18, includesa policy repository 17 to store a policy that has one or moremulti-factor conditions, as well as a wireless interface 19 to receive arequest from the security module 24 c of the vehicle and transmit thepolicy to the security module 24 c in response to the request. In oneexample, the policy is a user profile. As already noted, a givenmulti-factor condition may indicate whether the functions 26 of thevehicle are to be accessible if either the first mobile device 16 or thesecond mobile device 18 are not in proximity of the vehicle during anattempted access of the functions 26 of the vehicle. The policy may betransmitted to the security module 24 c in conjunction with a pairingprocess and/or an attempt to access one or more of the functions 26 ofthe vehicle.

With further regard to the pairing process, the illustrated mobiledevices 16, 18 also include a pairing module 21 that is configured topair the respective device with the vehicle and/or other devices. In oneexample, the pairing module 21 of the first mobile device 16 receives apasscode via the UI 30 and determines whether the passcode satisfies alogin constraint of the policy, wherein the first mobile device 16 ispaired if the passcode satisfies the login constraint. Similarly, thepairing module 21 of the second mobile device 18 may receive a passcodevia the UI 32 and determine whether the passcode satisfies the loginconstraint of the policy, wherein the second mobile device 18 is pairedif the passcode satisfies the login constraint. Alternatively, thedetermination as to whether the passcode satisfies the login constraintmay be conducted by the vehicle. Moreover, in some instances, a mobiledevice such as, for example, the first mobile device 16 (e.g., key fob)may not have the capability to support the entry of login credentials.In such a case, the UI 34 of the vehicle may be used, or the loginprocess may be bypassed altogether if the device is a master device.

FIG. 4 shows a set of user profiles 28 structured as a table. In theillustrated example, a plurality of users (e.g., “Dad”, “Mom”, “Sally”)each has various preferences that are programmable/configurable. Forexample, a passcode, the number of factors required to access thevehicle (“Access Factors”), the number of factors required to activatethe vehicle ignition (“Start Factors”), the number of factors requiredto operate the vehicle (“Drive Factors”), location constraints, timeconstraints, and so forth, may all be defined on a user-by-user basis.Moreover, the specified parameters may be used to determine whether togrant user requests, as well as to apply user-specific conditions togranted requests. Of particular note is that different users may havedifferent policies. For example, Mom and Dad are able to start thevehicle with only one factor present, whereas Sally's profile calls fortwo factors to be present in order to start the vehicle, in theillustrated example. Although the illustrated set of user profiles 28 isstructured as a table, the set of user profiles 28 may also utilizeother known structures such as relational database structures and/orlinked lists to track, manage, control and organize the data representedtherein.

Turning now to FIG. 5, a method 44 of managing a multi-factorauthentication environment is shown. The method 44 may be implemented asa set of logic instructions and/or firmware stored in a machine- orcomputer-readable storage medium such as random access memory (RAM),read only memory (ROM), programmable ROM (PROM), flash memory, etc., inconfigurable logic such as, for example, programmable logic arrays(PLAs), field programmable gate arrays (FPGAs), complex programmablelogic devices (CPLDs), in fixed-functionality logic hardware usingcircuit technology such as, for example, application specific integratedcircuit (ASIC), complementary metal oxide semiconductor (CMOS) ortransistor-transistor logic (TTL) technology, or any combinationthereof. For example, computer program code to carry out operationsshown in the method 44 may be written in any combination of one or moreprogramming languages, including an object oriented programming languagesuch as C++ or the like and conventional procedural programminglanguages, such as the “C” programming language or similar programminglanguages. Moreover, the method 44 may be implemented as the logicarchitecture 24 (FIG. 3) using any of the aforementioned circuittechnologies.

Illustrated processing block 46 provides for receiving a user requestvia a user interface of, for example, a first mobile device, a secondmobile device, a vehicle, and so forth. The user request may correspondto one or more functions of the vehicle such as a door unlock function(e.g., access request), an ignition function (e.g., start request), auser setting function (e.g., seat preferences, radio preferences), avehicle operation function (e.g., placing/maintaining the transmissionin drive), a pairing function (e.g., replacement device), and so forth.A determination may be made at block 48 as to whether a multi-factorcondition is satisfied. As already noted, the multi-factor condition maytake into consideration a first proximity status of a first mobiledevice with respect to the vehicle, a second proximity status of asecond mobile device with respect to the vehicle, etc., wherein themulti-factor condition may specify whether both mobile devices are to bepresent in order to make the vehicle function in question available tothe user. If the multi-factor condition is not satisfied, block 52 maydeny the user request. Block 52 may also provide for generating anotification via user interface of, for example, the first mobiledevice, the second mobile device, the vehicle, or any combinationthereof, in order to inform the vehicle owner of a missing, lost and/orstolen mobile device, as already discussed.

If, on the other hand, the multi-factor condition is satisfied,illustrated block 50 grants the user request and applies any relevantconstraints to the request. Both the multi-factor condition and theconstraints may be defined on a user-by-user basis and stored in anappropriate profile, policy, etc. In one example, the constraint is alocation constraint in which the vehicle function is only available incertain locations. In another example, the constraint is a timeconstraint in which the vehicle function is only available at certaintimes and/or for certain durations of time. In yet another example, theconstraint is a login constraint in which the vehicle function is onlyavailable if the user inputs a predetermined passcode. The loginconstraint may be particularly useful for pairing devices andreplacement devices.

FIG. 6 illustrates a processor core 200 according to one embodiment. Theprocessor core 200 may be the core for any type of processor, such as amicro-processor, an embedded processor, a digital signal processor(DSP), a network processor, or other device to execute code. Althoughonly one processor core 200 is illustrated in FIG. 6, a processingelement may alternatively include more than one of the processor core200 illustrated in FIG. 6. The processor core 200 may be asingle-threaded core or, for at least one embodiment, the processor core200 may be multithreaded in that it may include more than one hardwarethread context (or “logical processor”) per core.

FIG. 6 also illustrates a memory 270 coupled to the processor 200. Thememory 270 may be any of a wide variety of memories (including variouslayers of memory hierarchy) as are known or otherwise available to thoseof skill in the art. The memory 270 may include one or more code 213instruction(s) to be executed by the processor 200 core, wherein thecode 213 may implement the logic architecture 24 (FIG. 3), alreadydiscussed. The processor core 200 follows a program sequence ofinstructions indicated by the code 213. Thus, the processor core 200 maybe part of a vehicle such as the vehicle 14 (FIG. 1). The processor core200 may also be used in a mobile device such as the mobile devices 16,18 (FIG. 3) to support the functionality of those devices. Eachinstruction may enter a front end portion 210 and be processed by one ormore decoders 220. The decoder 220 may generate as its output a microoperation such as a fixed width micro operation in a predefined format,or may generate other instructions, microinstructions, or controlsignals which reflect the original code instruction. The illustratedfront end 210 also includes register renaming logic 225 and schedulinglogic 230, which generally allocate resources and queue the operationcorresponding to the convert instruction for execution.

The processor 200 is shown including execution logic 250 having a set ofexecution units 255-1 through 255-N. Some embodiments may include anumber of execution units dedicated to specific functions or sets offunctions. Other embodiments may include only one execution unit or oneexecution unit that can perform a particular function. The illustratedexecution logic 250 performs the operations specified by codeinstructions.

After completion of execution of the operations specified by the codeinstructions, back end logic 260 retires the instructions of the code213. In one embodiment, the processor 200 allows out of order executionbut requires in order retirement of instructions. Retirement logic 265may take a variety of forms as known to those of skill in the art (e.g.,re-order buffers or the like). In this manner, the processor core 200 istransformed during execution of the code 213, at least in terms of theoutput generated by the decoder, the hardware registers and tablesutilized by the register renaming logic 225, and any registers (notshown) modified by the execution logic 250.

Although not illustrated in FIG. 6, a processing element may includeother elements on chip with the processor core 200. For example, aprocessing element may include memory control logic along with theprocessor core 200. The processing element may include I/O control logicand/or may include I/O control logic integrated with memory controllogic. The processing element may also include one or more caches.

Referring now to FIG. 7, shown is a block diagram of a system 1000 inaccordance with an embodiment of the present invention. In one example,the system 1000 is part of a vehicle such as the vehicle 14, alreadydiscussed. The system 1000 may also be used in a mobile device such asthe mobile devices 16, 18 (FIG. 3) to support the functionality of thosedevices. Shown in FIG. 7 is a multiprocessor system 1000 that includes afirst processing element 1070 and a second processing element 1080.While two processing elements 1070 and 1080 are shown, it is to beunderstood that an embodiment of system 1000 may also include only onesuch processing element.

System 1000 is illustrated as a point-to-point interconnect system,wherein the first processing element 1070 and second processing element1080 are coupled via a point-to-point interconnect 1050. It should beunderstood that any or all of the interconnects illustrated in FIG. 7may be implemented as a multi-drop bus rather than point-to-pointinterconnect.

As shown in FIG. 7, each of processing elements 1070 and 1080 may bemulticore processors, including first and second processor cores (i.e.,processor cores 1074 a and 1074 b and processor cores 1084 a and 1084b). Such cores 1074, 1074 b, 1084 a, 1084 b may be configured to executeinstruction code in a manner similar to that discussed above inconnection with FIG. 6.

Each processing element 1070, 1080 may include at least one shared cache1896. The shared cache 1896 a, 1896 b may store data (e.g.,instructions) that are utilized by one or more components of theprocessor, such as the cores 1074 a, 1074 b and 1084 a, 1084 b,respectively. For example, the shared cache may locally cache datastored in a memory 1032, 1034 (e.g., computer readable medium, computerreadable storage medium, etc.) for faster access by components of theprocessor. In one or more embodiments, the shared cache may include oneor more mid-level caches, such as level 2 (L2), level 3 (L3), level 4(L4), or other levels of cache, a last level cache (LLC), and/orcombinations thereof.

While shown with only two processing elements 1070, 1080, it is to beunderstood that the scope of the present invention is not so limited. Inother embodiments, one or more additional processing elements may bepresent in a given processor. Alternatively, one or more of processingelements 1070, 1080 may be an element other than a processor, such as anaccelerator or a field programmable gate array. For example, additionalprocessing element(s) may include additional processors(s) that are thesame as a first processor 1070, additional processor(s) that areheterogeneous or asymmetric to processor a first processor 1070,accelerators (such as, e.g., graphics accelerators or digital signalprocessing (DSP) units), field programmable gate arrays, or any otherprocessing element. There can be a variety of differences between theprocessing elements 1070, 1080 in terms of a spectrum of metrics ofmerit including architectural, microarchitectural, thermal, powerconsumption characteristics, and the like. These differences mayeffectively manifest themselves as asymmetry and heterogeneity amongstthe processing elements 1070, 1080. For at least one embodiment, thevarious processing elements 1070, 1080 may reside in the same diepackage.

First processing element 1070 may further include memory controllerlogic (MC) 1072 and point-to-point (P-P) interfaces 1076 and 1078.Similarly, second processing element 1080 may include a MC 1082 and P-Pinterfaces 1086 and 1088. As shown in FIG. 7, MC's 1072 and 1082 couplethe processors to respective memories, namely a memory 1032 and a memory1034, which may be portions of main memory locally attached to therespective processors. While the MC logic 1072 and 1082 is illustratedas integrated into the processing elements 1070, 1080, for alternativeembodiments the MC logic may be discrete logic outside the processingelements 1070, 1080 rather than integrated therein.

The first processing element 1070 and the second processing element 1080may be coupled to an I/O subsystem 1090 via P-P interconnects 1076, 1086and 1084, respectively. As shown in FIG. 7, the I/O subsystem 1090includes P-P interfaces 1094 and 1098. Furthermore, I/O subsystem 1090includes an interface 1092 to couple I/O subsystem 1090 with a highperformance graphics engine 1038. In one embodiment, bus 1049 may beused to couple graphics engine 1038 to I/O subsystem 1090. Alternately,a point-to-point interconnect 1039 may couple these components.

In turn, I/O subsystem 1090 may be coupled to a first bus 1016 via aninterface 1096. In one embodiment, the first bus 1016 may be aPeripheral Component Interconnect (PCI) bus, or a bus such as a PCIExpress bus or another third generation I/O interconnect bus, althoughthe scope of the present invention is not so limited.

As shown in FIG. 7, various I/O devices 1014 may be coupled to the firstbus 1016, along with a bus bridge 1018 which may couple the first bus1016 to a second bus 1020. The I/O devices 1014 may include, forexample, one or more proximity sensors that may be used to determine theproximity status of mobile devices with respect to a vehicle. Forexample, the proximity sensors may incorporate near field communications(NFC) technology, radio frequency identifier (RFID) technology, infrared(IR) technology, and so forth. In one embodiment, the second bus 1020may be a low pin count (LPC) bus. Various devices may be coupled to thesecond bus 1020 including, for example, a keyboard/mouse 1012,communication device(s) 1026 (which may in turn be in communication witha computer network, not shown), and a data storage unit 1018 such as adisk drive or other mass storage device which may include code 1030, inone embodiment. The code 1030 may include instructions for performingembodiments of one or more of the methods described above. Thus, theillustrated code 1030 may implement the logic architecture 24 (FIG. 3)and may be similar to the code 213 (FIG. 6), already discussed. Further,an audio I/O 1024 may be coupled to second bus 1020.

Note that other embodiments are contemplated. For example, instead ofthe point-to-point architecture of FIG. 7, a system may implement amulti-drop bus or another such communication topology. Also, theelements of FIG. 7 may alternatively be partitioned using more or fewerintegrated chips than shown in FIG. 7.

Technologies described herein may therefore reduce cost by enablinggeneral purpose devices such as smart phones, smart tables, etc., to beused for authentication purposes in a vehicle context. In addition,delays associated with replacing lost or stolen authentication devicesmay be significantly reduced due to the ability to pair a wide varietyof devices with the vehicle on-the-fly. Moreover, the use ofcustomizable profiles and/or policies to apply security constraints maybe much more convenient to users and may substantially enhance the userexperience. In addition, the mobile devices may be configured tocommunicate directly with the vehicle so that proximity statusinformation can be determined between a general purpose mobile deviceand the vehicle without involving an intermediary such as a serverand/or service provider.

Examples may include an apparatus having a first factor module todetermine a first proximity status of a first mobile device with respectto a vehicle and a second factor module to determine a second proximitystatus of a second mobile device with respect to the vehicle. Theapparatus may also include a security module to configure anaccessibility of one or more functions of the vehicle based at least inpart on the first proximity status and the second proximity status.

Additionally, the security module may identify a policy associated withone or more of the first mobile device and the second mobile device,wherein the accessibility is to be configured further based on thepolicy.

Additionally, the security module may receive a user request via a userinterface of one or more of the first mobile device, the second mobiledevice and the vehicle, wherein the accessibility is to be configured inresponse to the user request.

Moreover, the security module may include a denial component to deny theuser request if the first proximity status and the second proximitystatus do not satisfy a multi-factor condition of the policy.

In addition, the security module may include a grant component to grantthe user request if the first proximity status and the second proximitystatus satisfy a multi-factor condition of the policy.

In addition, the grant component may apply one or more of a timeconstraint of the policy, a location constraint of the policy, and alogin constraint of the policy to at least one of the one or morefunctions of the vehicle.

Moreover, the security module may include a notification component togenerate a notification via a user interface of one or more of the firstmobile device, the second mobile device and the vehicle if either thefirst proximity status indicates that the first mobile device is notpresent or the second proximity status indicates that the second mobiledevice is not present.

Additionally, at least one of the one or more functions of the vehiclemay include one or more of a door unlock function, a trunk unlockfunction, an ignition function, a user setting function, a vehicleoperation function, and a replacement device pairing function.

Additionally, any of the aforementioned apparatus examples may furtherinclude a proximity sensor, wherein the first factor module is to usethe proximity sensor to determine the first proximity status and thesecond factor module is to use the proximity sensor to determine thesecond proximity status.

Examples may also include a method in which a first proximity status ofa first mobile device is determined with respect to a vehicle. Themethod may also provide for determining a second proximity status of asecond mobile device with respect to the vehicle, and configuring anaccessibility of one or more functions of the vehicle based at least inpart on the first proximity status and the second proximity status.

Additionally, the method may further include identifying a policyassociated with one or more of the first mobile device and the secondmobile device, wherein the accessibility is configured further based onthe policy.

Additionally, the method may further include receiving a user requestvia a user interface of one or more of the first mobile device, thesecond mobile device and the vehicle, wherein the accessibility isconfigured in response to the user request.

Moreover, configuring the accessibility may include denying the userrequest if the first proximity status and the second proximity status donot satisfy a multi-factor condition of the policy.

In addition, configuring the accessibility may include granting the userrequest if the first proximity status and the second proximity statussatisfy a multi-factor condition of the policy.

In addition, configuring the accessibility may further include applyingone or more of a time constraint of the policy, a location constraint ofthe policy, and a login constraint of the policy to at least one of theone or more functions of the vehicle.

Moreover, configuring the accessibility may include generating anotification via a user interface of one or more of the first mobiledevice, the second mobile device and the vehicle if either the firstproximity status indicates that the first mobile device is not presentor the second proximity status indicates that the second mobile deviceis not present.

Additionally, in any of the aforementioned method examples, at least oneof the one or more functions of the vehicle may include one or more of adoor unlock function, a trunk unlock function, an ignition function, auser setting function, a vehicle operation function, and a replacementdevice pairing function.

Examples may also include at least one machine readable storage mediumhaving a set of instructions which, when executed by a processor, causea vehicle to perform any of the aforementioned method examples.

Moreover, examples may include a system having a proximity sensor and afirst factor module to use the proximity sensor to determine a firstproximity status of a first mobile device with respect to a vehicle. Thesystem may also have a second factor module to use the proximity sensorto determine a second proximity status of a second mobile device withrespect to the vehicle, and a security module to configure anaccessibility of one or more functions of the vehicle based at least inpart on the first proximity status and the second proximity status.

Examples may also include a mobile device having a policy repository tostore a policy with a multi-factor condition. The mobile device may alsoinclude a wireless interface to receive a request from a security moduleof a vehicle and transmit the policy to the security module in responseto the request.

Additionally, the multi-factor condition may indicate whether one ormore functions are to be accessible if either the first mobile device ora second mobile device are not in proximity of the vehicle.

Additionally, the mobile device may further include a pairing module topair the first mobile device with the vehicle.

Moreover, the pairing module may receive a passcode via a user interfaceof the first mobile device, wherein the first mobile device is to bepaired with the vehicle only if the passcode satisfies a loginconstraint of the policy.

In addition, the wireless interface may receive a notification that thefirst mobile device is a master device, wherein the policy is to includea plurality of user profiles.

In addition, the wireless interface of any of the aforementioned mobiledevice examples may receive a notification that either the first mobiledevice or the second mobile device is not within proximity of thevehicle during an attempted access of one or more functions of thevehicle.

Examples may also include at least one machine readable storage mediumcomprising a set of instructions which, when executed by a processor,cause a first mobile device to perform methods of any of theaforementioned mobile device examples.

Various embodiments may be implemented using hardware elements, softwareelements, or a combination of both. Examples of hardware elements mayinclude processors, microprocessors, circuits, circuit elements (e.g.,transistors, resistors, capacitors, inductors, and so forth), integratedcircuits, application specific integrated circuits (ASIC), programmablelogic devices (PLD), digital signal processors (DSP), field programmablegate arrays (FPGAs), logic gates, registers, semiconductor devices,chips, microchips, chip sets, and so forth. Examples of software mayinclude software components, programs, applications, computer programs,application programs, system programs, machine programs, operatingsystem software, middleware, firmware, software modules, routines,subroutines, functions, methods, procedures, software interfaces,application program interfaces (API), instruction sets, computing code,computer code, code segments, computer code segments, words, values,symbols, or any combination thereof. Determining whether an embodimentis implemented using hardware elements and/or software elements may varyin accordance with any number of factors, such as desired computationalrate, power levels, heat tolerances, processing cycle budget, input datarates, output data rates, memory resources, data bus speeds and otherdesign or performance constraints.

One or more aspects of at least one embodiment may be implemented byrepresentative instructions stored on a machine-readable medium whichrepresents various logic within the processor, which when read by amachine causes the machine to fabricate logic to perform the techniquesdescribed herein. Such representations, known as “IP cores” may bestored on a tangible, machine readable medium and supplied to variouscustomers or manufacturing facilities to load into the fabricationmachines that actually make the logic or processor.

Embodiments of the present invention are applicable for use with alltypes of semiconductor integrated circuit (“IC”) chips. Examples ofthese IC chips include but are not limited to processors, controllers,chipset components, programmable logic arrays (PLAs), memory chips,network chips, and the like. In addition, in some of the drawings,signal conductor lines are represented with lines. Some may bedifferent, to indicate more constituent signal paths, have a numberlabel, to indicate a number of constituent signal paths, and/or havearrows at one or more ends, to indicate primary information flowdirection. This, however, should not be construed in a limiting manner.Rather, such added detail may be used in connection with one or moreexemplary embodiments to facilitate easier understanding of a circuit.Any represented signal lines, whether or not having additionalinformation, may actually comprise one or more signals that may travelin multiple directions and may be implemented with any suitable type ofsignal scheme, e.g., digital or analog lines implemented withdifferential pairs, optical fiber lines, and/or single-ended lines.

Example sizes/models/values/ranges may have been given, althoughembodiments of the present invention are not limited to the same. Asmanufacturing techniques (e.g., photolithography) mature over time, itis expected that devices of smaller size may be manufactured. Inaddition, well known power/ground connections to IC chips and othercomponents may or may not be shown within the figures, for simplicity ofillustration and discussion, and so as not to obscure certain aspects ofthe embodiments of the invention. Further, arrangements may be shown inblock diagram form in order to avoid obscuring embodiments of theinvention, and also in view of the fact that specifics with respect toimplementation of such block diagram arrangements are highly dependentupon the platform within which the embodiment is to be implemented,i.e., such specifics should be well within purview of one skilled in theart. Where specific details (e.g., circuits) are set forth in order todescribe example embodiments of the invention, it should be apparent toone skilled in the art that embodiments of the invention can bepracticed without, or with variation of, these specific details. Thedescription is thus to be regarded as illustrative instead of limiting.

Some embodiments may be implemented, for example, using a machine ortangible computer-readable medium or article which may store aninstruction or a set of instructions that, if executed by a machine, maycause the machine to perform a method and/or operations in accordancewith the embodiments. Such a machine may include, for example, anysuitable processing platform, computing platform, computing device,processing device, computing system, processing system, computer,processor, or the like, and may be implemented using any suitablecombination of hardware and/or software. The machine-readable medium orarticle may include, for example, any suitable type of memory unit,memory device, memory article, memory medium, storage device, storagearticle, storage medium and/or storage unit, for example, memory,removable or non-removable media, erasable or non-erasable media,writeable or re-writeable media, digital or analog media, hard disk,floppy disk, Compact Disk Read Only Memory (CD-ROM), Compact DiskRecordable (CD-R), Compact Disk Rewriteable (CD-RW), optical disk,magnetic media, magneto-optical media, removable memory cards or disks,various types of Digital Versatile Disk (DVD), a tape, a cassette, orthe like. The instructions may include any suitable type of code, suchas source code, compiled code, interpreted code, executable code, staticcode, dynamic code, encrypted code, and the like, implemented using anysuitable high-level, low-level, object-oriented, visual, compiled and/orinterpreted programming language.

Unless specifically stated otherwise, it may be appreciated that termssuch as “processing,” “computing,” “calculating,” “determining,” or thelike, refer to the action and/or processes of a computer or computingsystem, or similar electronic computing device, that manipulates and/ortransforms data represented as physical quantities (e.g., electronic)within the computing system's registers and/or memories into other datasimilarly represented as physical quantities within the computingsystem's memories, registers or other such information storage,transmission or display devices. The embodiments are not limited in thiscontext.

The term “coupled” may be used herein to refer to any type ofrelationship, direct or indirect, between the components in question,and may apply to electrical, mechanical, fluid, optical,electromagnetic, electromechanical or other connections. In addition,the terms “first”, “second”, etc. may be used herein only to facilitatediscussion, and carry no particular temporal or chronologicalsignificance unless otherwise indicated.

Those skilled in the art will appreciate from the foregoing descriptionthat the broad techniques of the embodiments of the present inventioncan be implemented in a variety of forms. Therefore, while theembodiments of this invention have been described in connection withparticular examples thereof, the true scope of the embodiments of theinvention should not be so limited since other modifications will becomeapparent to the skilled practitioner upon a study of the drawings,specification, and following claims.

We claim:
 1. At least one non-transitory machine readable storage mediumcomprising a set of instructions which, when executed by a processor,cause a first mobile device to: store a policy including a multi-factorcondition that is to include a number uniquely configured for a userstating how many devices are to be required to allow a function of avehicle to be accessible to the user; receive a request from a securitymodule of the vehicle; and transmit the policy to the security module inresponse to the request.
 2. The at least one medium of claim 1, whereinthe multi-factor condition is to indicate whether the one or morefunctions are to be accessible if either the first mobile device or asecond mobile device are not in proximity of the vehicle.
 3. The atleast one medium of claim 1, wherein the instructions, when executed,cause the first mobile device to pair the first mobile device with thevehicle.
 4. The at least one medium of claim 3, wherein theinstructions, when executed, cause the first mobile device to receive apasscode via a user interface of the first mobile device, and whereinthe first mobile device is to be paired with the vehicle only if thepasscode satisfies a login constraint of the policy.
 5. The at least onemedium of claim 1, wherein the instructions, when executed, cause thefirst mobile device to receive a notification that the first mobiledevice is a master device, and wherein the policy is to include aplurality of user profiles.
 6. The at least one medium of claim 1,wherein the instructions, when executed, cause the first mobile deviceto receive a notification that either the first mobile device or asecond mobile device is not within proximity of the vehicle during anattempted access of one or more functions of the vehicle.
 7. At leastone non-transitory machine readable storage medium comprising a set ofinstructions which, when executed by a processor, cause a vehicle to:determine a first proximity status of a first mobile device with respectto the vehicle; determine a second proximity status of a second mobiledevice with respect to the vehicle; configure an accessibility of one ormore functions of the vehicle based at least in part the first proximitystatus and the second proximity status; and identify a policy associatedwith one or more of the first mobile device and the second mobiledevice, wherein the accessibility is to be configured further based onthe policy, wherein the policy is to include a number uniquelyconfigured for a user stating how many devices are to be required toallow a function of the vehicle to be accessible to the user.
 8. The atleast one machine readable storage medium of claim 7, wherein theinstructions, when executed, cause the vehicle to receive a user requestvia a user interface of one or more of the first mobile device, thesecond mobile device and the vehicle, wherein the accessibility is beconfigured in response to the user request.
 9. The at least one machinereadable storage medium of claim 8, wherein the instructions, whenexecuted, cause the vehicle to deny the user request if the firstproximity status and the second proximity status do not satisfy amulti-factor condition of the policy that is to include the number. 10.The at least one machine readable storage medium of claim 8, wherein theinstructions, when executed, cause the vehicle to grant the user requestif the first proximity status and the second proximity status satisfy amulti-factor condition of the policy that is to include the number. 11.The at least one machine readable storage medium of claim 7, wherein theinstructions, when executed, cause the vehicle to apply one or more of atime constraint of the policy, a location constraint of the policy, anda login constraint of the policy to at least one of the one or morefunctions of the vehicle.
 12. The at least one machine readable storagemedium of claim 7, wherein the instructions, when executed, cause thevehicle to generate a notification via a user interface of one or moreof the first mobile device, the second mobile device and the vehicle toannounce that either the first mobile device is not present or thesecond mobile device is not present.
 13. The at least one machinereadable storage medium of claim 7, wherein at least one of the one ormore functions of the vehicle includes one or more of a door unlockfunction, a trunk unlock function, an ignition function, a user settingfunction, a vehicle operation function, and a replacement device pairingfunction.
 14. An apparatus comprising: a first factor module todetermine a first proximity status of a first mobile device with respectto a vehicle; a second factor module to determine a second proximitystatus of a second mobile device with respect to the vehicle; and asecurity module to configure an accessibility of one or more functionsof the vehicle based at least in part the first proximity status and thesecond proximity status, the security module further to identify apolicy associated with one or more of the first mobile device and thesecond mobile device, wherein the accessibility is to be configuredfurther based on the policy, wherein the policy is to include a numberuniquely configured for a user stating how many devices are to berequired to allow a function of the vehicle to be accessible to theuser.
 15. The apparatus of claim 14, wherein the security module furtherto receive a user request via a user interface of one or more of thefirst mobile device, the second mobile device and the vehicle, whereinthe accessibility is to be configured in response to the user request.16. The apparatus of claim 15, wherein the security module includes adenial component to deny the user request if the first proximity statusand the second proximity status do not satisfy a multi-factor conditionof the policy that is to include the number.
 17. The apparatus of claim15, wherein the security module includes a grant component to grant theuser request if the first proximity status and the second proximitystatus satisfy a multi-factor condition of the policy that is to includethe number.
 18. The apparatus of claim 14, wherein the grant componentfurther to apply one or more of a time constraint of the policy, alocation constraint of the policy, and a login constraint of the policyto at least one of the one or more functions of the vehicle.
 19. Theapparatus of claim 14, wherein the security module includes anotification component to generate a notification via a user interfaceof one or more of the first mobile device, the second mobile device andthe vehicle to announce that either the first mobile device is notpresent or the second mobile device is not present.
 20. The apparatus ofclaim 14, wherein at least one of the one or more functions of thevehicle is to include one or more of a door unlock function, a trunkunlock function, an ignition function, a user setting function, avehicle operation function, and a replacement device pairing function.21. The apparatus of claim 14, further including a proximity sensor,wherein the first factor module further to use the proximity sensor todetermine the first proximity status and the second factor module is touse the proximity sensor to determine the second proximity status.
 22. Amobile device comprising: a policy repository to store a policyincluding a multi-factor condition that is to include a number uniquelyconfigured for a user stating how many devices are to be required toallow a function of a vehicle to be accessible to the user; and awireless interface to receive a request from a security module of thevehicle and transmit the policy to the security module in response tothe request.
 23. The mobile device of claim 22, wherein the multi-factorcondition further to indicate whether the one or more functions are tobe accessible if either the first mobile device or a second mobiledevice are not in proximity of the vehicle.
 24. The mobile device ofclaim 22, further including a pairing module to pair the first mobiledevice with the vehicle.
 25. The mobile device of claim 24, wherein thepairing module further to receive a passcode via a user interface of thefirst mobile device, and wherein the first mobile device is to be pairedwith the vehicle only if the passcode satisfies a login constraint ofthe policy.
 26. The mobile device of claim 22, wherein the wirelessinterface further to receive a notification that the first mobile deviceis a master device, and wherein the policy is to include a plurality ofuser profiles.
 27. The mobile device of claim 22, wherein the wirelessinterface further to receive a notification that either the first mobiledevice or the second mobile device is not within proximity of thevehicle during an attempted access of one or more functions of thevehicle.
 28. The at least one machine readable storage medium of claim11, wherein the time constraint is to include a period of time uniquelyconfigured for the user within which the user is to be allowed to accessthe function, and the location constraint to include a geographiclocation uniquely configured for the user within which the user is to beallowed to access the function.
 29. The at least one machine readablestorage medium of claim 1, wherein two or more users are each to beassociated with a uniquely configured number of equal value for a samefunction and with a different uniquely configured constraint, and two ormore users are each to be associated with a uniquely configured numberof equal value for a same function and with a same uniquely configuredconstraint.